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Although  the  .IOVIAI  Compiler  Implementation  Tool  l.IOCITt  produced  the  most 
"it-ltke11  .IOVIAI  compiler  built  to  date,  the  Air  Force  was  not  at  liberty  to 
develop  compilers  for  other  systems  because  of  the  proprietary  nature  of  the 
UK' IT  module,  CENESIS.  The  Intent  of  this  effort  was  to  lease  CKNES1S  and  to 
make  various  Improvements  to  J0C1T.  These  Improvements  Included  fortifying 
the  .IOC IT  optimizer  with  state-of-the-art  optimizing  features.  For  the  most 
part,  this  effort  accomplished  the  above,  but  resulted  In  the  development  ot 


1473  I OITION  Ok  1 NOV  A»  IS  OBSOl  IT» 


DNl  I.ASS  IF!  KD 

V*  a 11  Hi  Mil  ASM  ► mat  ION  O*  T MiS  P Ant  , Pat*  KrtlStfd 

* It  0 9 (UO 


UNCLASSIFIED 


d 


security  classification  of  this  p AGgfWhan  n*tm  Enffd) 


two  separate  optimizers.  Additional  Improvements  Included  optimizing  the 
SYMPI.  compiler  module  of  JOCIT  and  Implementing  an  ASCII  and  floating  point 
double  precision  data  processing  capability  In  the  JOCIT  produced  compilers. 
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EVALUATION 


Because  of  the  wide  acceptance  of  RADC's  JOVIAL  Compiler 
Implementation  Tool  (JOCIT),  demands  were  made  on  the  Air  Force 
to  secure  full  rights  to  the  JOCIT  system.  Consequently,  this 
effort,  entitled,  "Improvements  to  JOCIT",  was  initiated  to 
lease  the  proprietary  meta-compiler,  GENESIS,  giving  the  Air 
Force  complete  control  of  the  tool  and  to  incorporate  state-of- 
the-art  optimization  technqiues  into  JOCIT  and  the  JOCIT 
building  language,  SYMPL. 

This  effort  fell  short  of  RADC's  expectations,  insofar  as 
two  JOCIT  optimizers  were  delivered  instead  of  one;  however,  a 
DOD  "first"  was  realized  in  creating  a 99-year  software  lease 
with  Computer  Sciences  Corporation  for  the  rights  to  GENESIS. 

In  addition  to  the  above,  this  contract  served  as  a vehicle  for 
producing  double  precision  floating  point  and  ASCII  data 
handling  capabilities  for  the  JOCIT  system  and  initiated  the 
updating  of  the  JOVIAL  J3  specification,  MIL-STD  1588. 

RICHARD  M.  MOTTO 
Project  Engineer 
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IM'UUULCTION  AND  Sl'MMAKY 


The  'Improvements  to  JOCIT"  contract  was  awarded  to  improve  the  operation  and 
versatility  of  the  JOVIAL  Compiler  Implementation  Tool  (JOCIT)  so  that  it  would  be 
more  practical  and  conducive  to  use  in  a central  Higher  Order  Language  (HOI.)  con- 
trol facility.  JOCIT  is  operational  at  Home  Air  Development  Center  (RAI)C)  at 
Griffiss  AFH,  New  York  and  pci  .nits  Hie  got-, "ration  of  high  quality  JOVIAL  (J.'t) 
compilers. 

Initially  the  contract  called  for  the  transfer  of  the  GKNKSIS  Meta-Compiler  to  oper- 
ate on  the  HADC  HIS  <>00/ G000  computer  complex.  GENESIS  is  a Computer  Sciences 
Corporation  proprietary  system  for  producing  language  syntax  tables  suitable  for 
use  in  certain  types  of  syntax-directed  compilers  from  a convenient  syntax  descrip- 
tion language.  Also,  the  SYM1M.  compiler  (the  language  in  which  the  majority  of 
the  modules  in  the  JOVIAL  and  SYMl’I.  compilers  arc  written)  was  to  be  modified 
so  that  more  of  the  computer  independent  portions  of  the  compiler  resided  in  the 
"front-end".  Additional  optimization  techniques  were  to  be  added  to  the  SYMPI.  com- 
piler. Finally,  optimization  techniques  such  as  "code-straightening"  and  "dead- 
variable  analysis"  were  to  be  added  to  the  JOVIAL  compiler. 

Subsequently  the  contract  was  modified  to  include  the  addition  of  a double  precision 
floating  point  capability  not  previously  available  in  the  JOVIAL  compiler  and  to  re- 
write the  JOVIAL  ( J 3 ) MIL-S' TD- 1!>88  dated  JO  June  1!)7<>,  to  reflect  the  double  pre- 
cision floating  point  format  and  all  other  updates  resulting  from  the  JOCIT  imple- 
mentation of  JOVIAL. 

The  installation  of  GENESIS  was  accomplished  with  virtually  no  problems  and  will 
not  be  discussed  further  in  this  report.  The  rewrite  of  the  MlL-STD-lf>ss  was  much 
more  extensive  than  originally  anticipated.  The  changes  were  of  such  a magnitude 
that  the  entire  document  was  renumbered  and  completely  retyped. 

The  changes  to  the  JOVIAL  optimizer  were  more  complex  and  required  considerably 
more  effort  than  was  initially  thought  necessary.  Originally  the  plan  was  to  add  the 
new  optimizations  into  the  existing  optimizer.  However,  after  some  study,  this  plan 

was  abandoned  in  favor  of  producing  a new  optimizer  which  would  replace  the  existing 

1 


one.  This  decision  was  partially  based  on  the  fact  that  the  existing  optimizer  was 
somewhat  unstable,  particularly  with  large  programs.  Therefore  it  was  believed 
that  major  modifications  to  the  existing  optimizer  might  increase  the  instability  to 
an  unacceptable  level  and  require  more  effort  to  correct  the  situation  than  would  be 
expended  in  rewriting  the  optimizer.  Rewriting  the  optimizer  was  begun  with  the 
new  optimizations  such  as  code-straightening  and  dead- variable  analysis.  After  pro- 
ceeding with  this  plan  for  several  months,  it  became  increasingly  obvious  that  there 
was  neither  enough  time  or  money  to  complete  an  entire  replacement  for  the  old 
optimizer.  In  order  to  provide  the  maximum  possible  optimizations  for  JOVIAL, 
a new  plan  was  adopted.  The  old  optimizer  would  be  left  as  it  was  ami  the  new  opti- 
mizations would  lie  added  as  a separate  phase.  Additionally  it  was  decided  to  permit 
the  old  optimizer  phase  and  the  new  optimizer  phase  to  lie  run  optionally  and  inde- 
pendently of  one  another.  The  only  restriction  to  the  optimizers  is  that  the  old  opti- 
mizer, if  it  is  run,  must  run  before  the  new  optimizer.  Kven  adopting  this  method 
required  considerably  more  time  and  manpower  than  was  originally  contracted. 

A considerable  amount  of  testing  was  accomplished  on  the  new  optimizations.  In 
addition  to  the  JOVIAL  Compiler  V alidation  System  (JC'VS)  tests,  there  were  four- 
teen Strategic  Air  Command  (SAC)  programs  which  could  not  be  run  through  the  old 
optimizer  without  fatal  errors.  At  the  conclusion  of  the  optimizer  testing,  all  of  the 
fourteen  S/\C  programs  had  at  one  time  or  another  been  successfully  optimized 
through  the  new  optimizer.  Also,  twelve  of  the  fourteen  SAC  programs  had  been 
successfully  compiled  through  the  old  optimizer  thanks  to  some  changes  made  by  a 
former  employee  of  Computer  Sciences  Corporation,  it  was  not  possible  to  do  testing 
on  the  SAC  programs  with  the  final  compiler  delivered,  because  they  were  de- 
leted from  the  KAIH'  Computer  System.  The  new  optimizer  handled  all  the  JCVS 
tests  with  the  exception  of  the  large  Class  1 tests.  Five  of  these  six  tests  had  pro- 
blems, primarily  in  the  area  of  limitation  of  table  space.  However,  two  of  these 
five  tests  do  compile  when  using  both  optimizers.  Appendix  z\  of  this  report  shows 
the  time  of  compilation  and  object  program  size  of  the  various  modes  of  optimization 
for  the  JCVS  tests  and  the  SAC  programs.  Cenerally  there  is  improvement  in  the 


i'\'t  tmt  .od  proo.i.iiii  st/os  with  tin*  now  opt  fm  I /or  . Thorn  roiiialti,  howovoi  , .1 
niimhor  >'l  improvotnonts  whioh  would  : u l > 1 t o the  offiolonoy  >>1  tho  oompllod  programs. 
Phoso  inoludo  oomplutlon  of  rodistrihution  :unl  tlu-  addition  of  stron^th  roduotion, 
ti">t  roplnoomont,  varlahlo  ovorl av , rontstor  allooatton  and  nonoralt/od  name  doltnt 
tii'n  Also  analysis. 

A numhnr  i'l  modifioations  wen*  mado  ti>  tho  SVMl’l  oompilor  to  tmprovo  its  opora 
Hon.  I’Ih-  most  notiooal'lo  was  ulian^ing,  this  oompilor  from  two  phasos  to  throo 
phasos.  Phis  roduood  tin-  ooro  si.o  roi|iilrod  for  a SYMPl  oompilation  from  Ink  to 
\t  tlio  suin'  timo  iu'\v  optimi/ ations  worn  addod  and  tho  oompilor  was  niaiio 
moro  portal'lo  by  roar raipdiu’.  maohino  ilopi'inlont  ooiio  into  towor  modulos,  Posting 
ot  tho  now  s\  M I’l  oompilor  was  vor\  oxlonstvo,  inoliuliny,  oomptltnp,  tho  SYMPl 
moihilos  throup.h  itsolf  to  onsiiro  tho  oompilor  was  stal'lo.  Additionally,  all  tho 
,U'\I  At  nii'ilulos  writton  in  S\  MI'l  woro  rooompiloil  and  ItnUod  into  a tost  oompilor 
that  oxooiitod  tho  dt'VS  tosts  as  wo  1 I as  tin-  10V I A I oompilor  pi  oduood  bv  tho 
old  SY'11’1  oompilor. 

Iho  tinal  ohanpo  to.UH'IP  aooompli  hod  ntidor  tin-,  oontraot  was  tho  addition  of  a 
donl'lo  proot  . ton  t'apal'il  it  \ to  tho  di  ’\  I A I oompilor.  Ihis  also  nooossitatod  tho 
rooi'ttnition  of  donl'lo  prooision  b\  tho  SY  \ 1 P I oompilor.  I'haiis'.os  woro  roqiiii'od 
throui'.hoiit  tho.H'VlAI  oompilor  iiii'lndinp.  t ho  analysts,  allooation,  diroot  oodo, 
oodo  ponorator  and  oditor  phasos  as  woll  as  tho  run  timo  library.  Posting  was 
ai'oi'inpl i shod  hv  toniporan  I'hanp.i"-  to  tho  ,U  \ S tosts.  I ho  n'siilts  ot  thoso  tosts 
indioato  that  tho  donl'lo  prooision  oapal'ilitv  is  now  a solid  part  ot  tho  .H'\  1A1  00m 
pilot-  and  oan  ho  usi-d  oonfidontlv.  Ilowovor,  pormauont  donl'lo  prooision  tostinn 
should  ho  addod  to  ,li'\  S for  futuru  oompilor  \ or  it  loat  1011. 

I ho  final  rosult  ot  this  oontraot  was  tho  produotion  ot  a now  .H'YIAI  oompilor  wlifolt 
is  siipi'rior  to  tho  proviims  0110,  I'lio  amount  of  timo  and  otfort  rotpiirod  to  aohtovo 
this  was  undorostimatod  and  rosultod  in  towor  optimi.  ations  than  woro  originally 
antiotpatod.  Sovoral  timo  oxtonsioiis  woro  also  ronuirod.  I'lio  outiro  oontraot  was 
ai'Oi'inplishi'd  i'll  torminals  at  tho  oontraotors  taoility  w ith  tho  oxooption  ol  two  man 
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weeks  at  RA1H’  during  final  testing.  1'hc  Time  Sharing  System  (TSS)  facility  of  the 
I’iC’OS  operating  system  for  the  Honeywell  0 0 0 series  computer  was  used  through- 
out the  contract.  While  this  arrangement  was  generally  satisfactory,  the  lack  of  a 
remote  high  speed  printer  capability  definitely  hindered  progress.  This  was  espe- 
cially true  during  the  final  debugging  stages,  l arge  listings  were  sent  by  air  freight 
from  KA1K'  on  a daily  basis,  but  this  usually  resulted  in  a two  or  three  day  turn- 
around period. 


During  the  course  of  this  contract,  a number  of  requests  were  received  concerning 
bugs  in  the  compiler,  particularly  in  the  optimizer.  However,  the  contract  did  not 
cover  maintenance  on  the  compiler  and  there  was  neither  the  time  nor  funds  avail- 
able to  investigate  these  reported  problems.  Assuming  that  .JOVIAL  (Jd)  will  con- 
tinue to  be  used  for  some  time,  there  definitely  should  be  an  on-goiug  maintenance 
program  for  JtH'l  I'.  I'his  could  be  accomplished  either  through  an  outside  contrac- 
tor or  in-house  if  the  talent  is  available.  However,  without  a centralized  n ponsible 
authority  for  future  development  and  maintenance,  the  optimum  usefulness  ot  this 
valuable  toed  will  not  be  realized. 
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In  order  to  make  the  <KKT  1 SYMPL  Compiler  more  portable  and  more  useful,  a 
number  of  enhaneements  have  been  implemented.  The  enhaneements  are  deseribed 
in  this  section. 


COMl’l  I I K IHKI  C 1'1\  I S 


Compiler  directives  have  been  redefined  as  deseribed  in  the  following  paragraphs 


Condi t ion. d_  lot npi  1 a_t ion 

skip  directive  : 
bet;in  di  reeliv  e : 
end  di  reetiv  e ;; 
block  indicator  : 
letter  a 


! S K 1 1 ' block  indieal or ; 

! H 1 a d N block  im lie. il>.) r ; 
! KM)  block  indicator; 


A through  /. 


H KC  IN  and  If  N 1)  di  reel  ives  hav  ini;  I he  same  block  indicator  delimit  a block  of  condit- 
ionally compiled  cod  Co  If  a skip  direct  ire  occurs  prior  to  the  block  and  has  the  same 
block  indicator,  the  code  within  the  block  is  not  compiled;  otherwise  the  code  is 

compiled. 


Listing  Options 

list  di  reetiv  e 


copy  diiaa  tiv  e 


! LIST 


!C01"i 


I !ox 

; . 1 OKKt  ' ; default  is  ON 

I • I 

t i is  r 1 

\ , o • ble  name ; 


lasting,  ,if  sourer  code  during  compilation  is  handled  in  a hierarchical  manner.  Die 
highest  level  is  the  compiler  switches.  It  the  NOl. IS  1'  option  is  selected,  no  listing 
will  occur  regardless  of  what  list  ilireetives  may  yir  may  not  lie  imlvddcd  in  t hi'  source, 
rhi'  next  levii  of  listing  is  the  program  itself.  lower  levels  arc  COl"t  files  and 
nested  OYP\  files.  It  a ! 1.1ST,  v)  KK  is  encountered  at  am  level,  listing  di  reetiv  os 
in  lower  levels  have  no  effect.  A ll'OPY  is  considered  at  a higher  level  than  the 
code  it  refers  to.  1'heri'lore,  all  listings  will  be  suppressed  until  the  code  is 


encountered.  A li'OPY,  LIS  I'  would  then  allow  listing  control  within  the  copy  file 
to  have  effect. 


1)01  HI  I-  PRI  VISION 

IXmblo  precision  lTKMs  may  be  declared  in  one  of  two  ways: 

\ K mantissa  / 

double  precision  item  I 1 1-.M  name  ^ ^ ; 

mantissa  : * integer  number 

If  the  numher  indicated  for  the  mantissa  in  a real  item  is  greater  than  the  number 
ol  bits  in  the  mantissa  of  a single  precision  number  of  the  target  machine,  the  item 
is  promoted  to  double  precision. 

Double  precison  constants  are  identical  to  single  precision  constants  except  that  ’K1 
is  replaced  In  MP  to  indicate  the  exponent. 

t'OM  I’ll  I R P.U  K1D  ARRAYS 

In  order  to  have  a greater  degree  of  machine  independence,  compiler  packed  arrays 
have  Ivon  implemented.  Arrays  now  have  the  following  syntax: 

c.p.  array  :«  ARRAY  name  [ dimension  ) 

array  layout  array  pack  tv  pe:  IT  KM  item  list; 


No  packing 
Medium  packing 
Dense  packing 
Specified  packing 
Default  is  N 


' item  dese.  , item  list 

' 0 


»P{ 

array  layout  ;j\S  detaelt  is  P 

( <f>  ‘ 


a rra  v pack  t v pe  :=•  v R 


1“  I 

| (entry  sire)  j 


i I pm  1 i 


i item  dose. 


i unspecified  array  in 
) specified  arnn  info. 


SIZi 


unspecified  array  info 


default  is  array  pack  type 


item  pack  typo 


(word,  fbi t , size) 


The  following  is  an  example  of  a compiler  packed  array 


\HH.\Y  XV  1 1(500]  S I);  IT  KM 
AH  f 2 N, 


l'he  lollowing  allocation  would  result  on  the  Honeywell  maehitu 


\otiee  that  AH  was  assigned  a lull  word  since  it  called  for  no  packing 


It  the  arra\  is  unspecified  and  one  of  its  items  is  speeitiod,  or  \ ice  yersa,  the 


following  error  message  will  he  generated 


mnconsls  ri:x  r with  aku ay 


PAKAM  KTKHIZK1)  ' 1 )K  F'  STATKM  KNTS 


"DKF"  statements  have  been  enhanced  to  allow  lor  embedded  parameters-  The 
following  defines  the  syntax: 

(elemdef  | 


OFF  clef  name 


del  dee 


.Tern  clef 


char  string 

K’har  string 


| lurni  del  | 


"char  string"  ; 

1 * I 

| char  string  | 


Where  tp  represents  any  punchable  eharaeter-  'i’wo  eonseeutive  double  quotes 
represent  a single  double  quote-  'Fwo  eonseeutive  exclamation  points  represent 
a single  one.  Single  exclamation  points  are  not  allowed. 

parm  del’  :=  (parm  list)  "parm  string" 

I parm  list,  | 


parm  list 


I letter  | 


parm  string  parm  string 
parm  string  { form  parm 
char  string 


/ 

I 


form  parm  :=•  ! letter 

There  must  be  a corres|>onding  letter  in  the  parameter  list  for  each  formal  parameter. 
When  using  the  defined  string,  any  unused  parameters  are  replaced  with  null  strings. 

For  example: 

I)KF  AHC(X,  Y,  7. ) "THAT  ! X MAN!  Y!X  IF  UK  UOKS!  Z ! ! " 

If  called  with 

AlU.’f’WKLL',  'SPKAKS',  'TOO  S(H)N') 
it  lx: comes 

THAT  WKKL  MAN  SPKAKS  WKLL  IF  11  K tIOKS  TOO  SOON! 

8 


or  it  ealled  with 


aik'  (,  • ls  in  ruornLi:') 
becomes 

THAT  MAN  kS  IN  TKOl'liKK  IK  1IK  t'.QKS! 

Ml  I. TIPI. K ASSll!  N mi:  NTS 

Heplaeement  statements  now  allow  tor  multiple  sinks  on  the  left  siile  of  the  equal 
sigti(-),  ami  have  the  following  sv ■ nt.ix : 


msink 


I 


replaeement  statement  . * sourer; 

— *- | tune  name  \ 

, | msink  , sink  I 

msink  , — — — ■ 

|mnk_  | 

All  sinks  on  the  lett  side  ol  the  equal  sign  ( -)  will  take  on  the  value  of  t In*  souree. 
f or  example  in 

\ t . \YZ(.n,  unit  it 

all  three  variables  are  set  to  zero. 
rOMPIKKK  1’IIASKS 

Previouslv , the  SN  Ml’l,  eompiler  eonsisted  of  two  phases  (eore  overlays!:  AN/K  and 
t om..  t’('l)K,  the  largest  phase,  was  broken  into  two  smaller  phases,  ('OI)K  and 
ASMItl.,  An  additional  seratelt  tile  has  Keen  alloeated  to  aeeommodate  the  objeet 
eode  intermediate  information.  These  ehanges  resulted  in  deereased  eore  alloeation. 
The  eompiler  now  oeeupies  a titilx  partition  instead  of  the  previous  -I UK  partition. 

I'll  I M IN  THAI'  TION  OPTIMIZATION 

A new  opt  i mi  /.at  ion  has  been  added  to  eanse  inoiv  I'ltieient  eode  to  be  generated  when 
assigning  one  field  (partial  word  table  item)  to  another..  Tor  example: 


A.\A(0)  unit  (tn 


Assuming  those  variables  were  alloeated  as  follows, 


IT  KM  AAA  l (0,  ti,  S), 

HUH  1(0,  is,  S); 

r hen  (In-  following  rode  would  have  boon  generated  in  the  previous  eompiler: 


l.pg 

HUM 

g 1 .s 

IS 

lx!  rael 

gui. 

US 

Position  for  Sion 

g l ,S 

L L 

l sing  the  new  eompiler,  the  following  eode  is  generated: 

I I Kk>  HltlS 

gl,S  l 2 Posit  ion  Onl\ 

I'ode  soi|iioneos  will  i a n , depending  on  wlietlier  the  items  are  signed  or  unsigned 
and  depending  on  the  length  of  the  items  with  respeel  to  eaeh  other,  1'hev  will, 
however,  generate  shorter  eode  sequonees  m most  eases,, 

SWTIVII  OPTIMIZATION 

\nothe  r opti  mi  /.at  ion  has  been  added  to  deereaso  eore  requirements  lor  large 
switeli  lists  (greater  than  I'.’  swileli  points).  I'nder  the  old  implementatniii  the 
switeli  value  is  used  as  an  index  into  a tump  table.  l-.aeli  entrx  ol  the  lump  table 
eonlaius  a TKA  mstruetion  whirl)  tumps  to  its  eor responding  program  label.  This 
implies  that  one  word  per  switeli  point  is  alloeated  in  data  spare. 

I'nder  the  new  implementation,  spare  is  eonservixl  In  assigning  two  switeli  points 
per  word  using  ottlv  the  address.  The  appropriate  lull-word  is  lo.ulrd  into  a 
register  and  an  indexed  transfer  oeeurs.. 
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The  following  is  an  example  of  a jump  table  under  both  methods; 


r 


Olil  New 


ZERO  Al,  A 2 
ZERO  A3,  Al 

. 

o • 

• • 

I 

I The  new  method  requires  slightly  more  overhead,  so  unless  a switch  list  contains 

more  than  12  switch  |K>ints,  the  old  method  is  still  used. 

ERROR  REPORTING 

The  following  error  messages  have  been  added  to  accommodate  the  new  compiler 
features: 

•INCORRECT  USE  OE  I)EF' 

'TOO  MANY  PARAMETERS' 

'INCONSISTENT  WITH  ARRAY' 

'MALFORMED  CODE  FILE' 

'MISSING  SEND* 

in  addition,  more  error  testing  has  been  added  to  the  expression  scanner  to  report 
previously  undiagnosed  errors. 


TRA  Al 
TRA  A 2 
TRA  A3 
TRA  Al 


1 1 


J 


I'll TUKf  OONSIDfKATlONS 


Tlu'  following  enhancements  to  the  SYM PL  compiler  could  l>e  implementeil  in  the 
tutu  re: 

l„  A modification  to  the  language  which  would  allow  the 

programmer  to  perform  array  element  and  array  moves, 
for  example: 

ARRAY  AHO  1 1 00 1 Syl); 


AURA  Y Off  1 10|  »'(  I ); 


AltO  | Sf» | Df.'f  (;!); 

I'liis  would  cause  four  words  from  a parallel  table  to  he 
moved  to  a serial  table- 

A re  evaluation  ol  code  generated  In  the  SYMl’l,  compiler  to 
make  use  of  special  instructions  for  better  localized  optimizations, 
for  example  using  AOS  instruction  it'  the  ease: 

YAK  YAK  i 1 

Reiter  code  generated  for  compound  If  statements.  The  current 
algorithm  calls  for  the  evaluation  of  each  element  of  the  compound 
If,  maintaining  a boolean  value  representing  the  sense  ot  the  If 
condition.  A better  approach  would  be  to  jump  out  immediately 
it  an  AND  condition  is  false  or  if  an  OK  condition  is  true. 


SUMMARY  or  MKNKl’Tl'S 

Benefits  derived  from  the  enhancements  done  on  the  SYMPL  compiler  not  only  have 
made  SYMPL  a more  portable  and  effective  implementation  tool,  but  have  also 
resulted  in  better  code  being  generated  for  both  SYMPL  and  JO  VIA  L.  In  some  eases, 
better  local  optimization  occurs  and,  in  the  case  of  switches,  more  efficient  data 
packing  occurs.  In  addition  the  systems  programmer  now  has  better  debugging  tools 
and  language  features. 


DOUBLE  PRECISION 


The  JOC1T  J:i  compiler  has  been  enhanced  with  a full  double  precision  arithmetic 
processing  data  structuring  and  diagnostic  capability.  These  enchancements  required 
modification  to  the  syntax  tables,  precognition  processing  (part  of  the  analyzer), 
pragmatic  functions,  direct  code  processing,  allocation,  code  generator,  editing  and 
library  segments  of  the  compiler  within  both  the  program  and  COM  TOOL  handling 
sections.  In  addition,  modifications  to  the  SYMPL  compiler  were  required  to  pro- 
cess double  precision  declarations  required  for  double  precision  compile-time  pro- 
cessing. 

SYNTAX  - VARIABLE  DECLARATIONS 

Both  the  compiler  syntax  (JSYN)  and  the  COMPOOI.  syntax  (CSYN)  were  modified  to 
recognize  the  following  double  precision  syntactical  contexts  and  to  establish  entry 
points  within  the  Pratmatic  Function  (PF1,  PF2)  segments  of  the  compiler: 

• Scalar  declarations  of  the  form 

ITEM  item-name  D $ 

• Array  declarations  of  the  form 

ARRAY  array-name  (dimension-list)  D $ 

• Table  item  declarations  for  both  ordinary  and  defined  table  declarations 
of  the  basic  form 

ITEM  table- item-name  D . . . $ 

• Mode  directives  of  the  form 

MODE  D $ 

PRECOGNITION  - CONSTANT  RECOGNITION 

The  precognition  segment  of  the  compiler  recognizes  references  to  double  precision 
constants  of  the  form 

Icontcxtl  1 . F D + E Icontext) 
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Where  I = interger  portion 
F*=  fractional  portion 
K=  exponent 

Examples:  0.025D 
1. 1)1 

l . 27(1320-10 

Double  precision  constants  are  recognized  in  the  following  contexts: 

• Arithmetic  expressions 

• Relational  expressions 

• Assignment  statements 

• Parameters 

• Presets 

The  necessary  modifications  to  the  Preset  Processor  were  minimal.  The  Preset 
routine  contains  calls  to  KONS.  The  second  parameter  of  each  call  was  changed 
from  a value  to  the  address  of  the  value  using  the  SYMPl.  l.OCN  internal  function. 
There  are  also  some  cases  where  the  call  to  KONS  lies  within  a loop.  Previously 
the  loop  increment  had  been  one  in  all  cases.  A double  precision  check  has  been 
inserted  in  these  places.  If  the  test  is  true,  the  loop  variable  is  set  to  two. 

PRAGMATIC  FPNCTIONS 

The  pragmatic  functions  PF1  and  PF2  are  defined  as  follows: 

PF1-  All  explicit  and  implicit  (MODE)  double  precision  declarations  of  scalars, 
arrays  and  table  items  are  posted  to  the  Symbol  Table  during  the  first 
syntactical  pass  (AN/l).  Double  precision  constant  references  that  have 
been  parsed  are  resolved  and  posted  to  the  Symbol  Table  as  two-word 
constants. 

PF2-  Double  precision  operand  contexts  are  processed  for  required  conversion 
precedence  determination,  and  legal  context  during  the  second  syntactical 
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pass  (AN'/2).  Double  precision  is  required  to  have  the  highest  prece- 
dence within  arithmetic  and  relational  expression  contexts.  Conversion 
from  or  to  double  precision  in  assignment  statements  is  dictated  by  the 
mode  of  the  receiving  item.  Conversion  from  or  to  double  precision  is 
accomplished  by  generation  of  the  appropriate  intrinsic  function  within 
the  Intermediate  language  passed  to  the  optimization  and/or  code  genera- 
tion phases  of  the  compiler. 

DIHKl’T  com-: 

I he  routines  which  handle  direct  code  were  modified  to  allow  double  precision  con- 
stants. Since  the  compiler  contains  many  status  lists  which  deal  with  the  type  of 
constants,  each  of  these  had  to  be  updated  to  include  a status  value  for  double  preci- 
sion. I lie  scanning  routine  was  modified  to  allow  constants  containing  the  letter  D. 
rhe  I)  indicates  the  end  of  the  characterisite  portion  of  the  value  and  the  beginning  of 
the  mantissa,  t he  rules  which  govern  the  syntax  of  single  precision  constants  (using 
the  letter  I-  instead!,  apply  in  the  same  manner.  Double  precision  variables  were 
added  to  the  compiler  to  internally  develop  the  value  of  the  constants. 

Al  l. OCA  HO N 

Double  precision  scalars  and  array  declarations,  exclusive  of  those  declared  in  com- 
mon, are  linked  to  force  allocation  to  an  even-word  addressing  boundary  for  optimal 
fetching  and  storage,  rhe  Sl.C  chains  arc  serially  searched  for  occurrence  of  double 
precision  variables,  and  are  relinked  accordingly. 

fODK  Cd-  NKHA  I OR 


I’he  code  generator  converts  the  input  II  sequence  to  a linked  triad  form,  then  pro- 
cesses the  triad  table  to  generate  output  code  to  the  code  file.  To  generate  double 
precision  code,  the  code  generator  takes  advantage  of  the  fact  that  for  the  host  machine 
of  th*'  .lot'll’  d.l  compiler,  the  double  precision  floating  point  register  overlaps  the 
single  precision  floating  point  register.  Therefore,  double  precision  floating  point 
follows  the  same  code  sequence  as  single  precision  floating  point.  In  addition,  a one 
bit  field  DI’FT  in  a triad  table  entry  is  used  as  a flag  to  indicate  that  this  triad  entry 


Is  n double  precision  primitive  item,  double  precision  value  triad,  or  a double  pre- 
cision expression. 


SETTING  I MF  PPF  r Tl.AG 
I'he  DPFT  flan  Is  set  whenever: 

1.  A double  precision  11.  operator  or  operand  is  encountered  o'-g..  HPFXP, 
DPI. IS  or  any  data  item  with  type  S'PIU.'  in  the  symbol  table!. 

2.  An  integer,  single  precision  item  is  converted  to  or  from  a double  preci- 
sion item  te.g.,  IPX,  PKXF 

d.  A two-word  temporary  triad  is  created. 

FSF  OF  I MF  PPF  V FI. AG 

Gonstant  Handling 

Gonstants  are  handled  as  follows: 

I.  The  front  end  routine  IVON  is  used  to  post  a double  precision  constant; 
l’K'ON  is  used  to  post  the  other  constants. 

II.  The  found  value  of  the  constant  is  returned  in  an  array  form,  instead  of 
just  a one  word  item  as  previously,  so  that  the  second  word  of  a double 
precision  item  can  be  retrieved. 

:t.  The  l.OGN  and  AS Ftj  fields  of  constant  entries  in  the  Symbol  ruble  arc 
rearranged  in  such  a way  that  all  double  precision  items  arc  grouped 
together  and  come  ahead  of  the  other  constants  and  literals.  I'hus,  the 
Editor  only  needs  to  align  the  constants  once. 

1 .ending,  Storing,  or  Other  Arithmetic  Operations 

If  the  actual  location  of  the  two  words  in  the  double  precision  operand  are  not  conti 
guous  (o.g.,  table  item!,  three  new  routines  accommodate  the  situations,  as  dos 
cribed  below. 

1.  PI  GAP  is  called  whenever  a load  instruction  of  a double  precision  item 

needs  to  be  generated.  If  the  operand  is  a table  item,  a series  of  mstruo 
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tions  will  be  generated,  e.g. : 


LDA  First  Word 

LDQ  Second  Word 

* STAQ  Temp 

* DFLD  Temp 

* (Not  generated  if  the  destination  register  is  an  AQ  pair  where  temp 
is  a two  word  temporary  location. ) 

Otherwise,  a single  instruction  LDAQ  or  DFLD  is  generated,  depend- 
ing on  the  specified  destination  register. 

2.  DSTORE  is  called  whenever  a store  instruction  to  a double  precision 

item  needs  to  be  generated.  If  the  operand  is  a table  item,  a series  of 
instructions  will  be  generated,  e.g.: 

I * I.DAQ  Temp**] 

ST  A First  Word 

STQ  Second  Word 

* (Not  generated  if  source  register  is  an  AQ  pair.) 

**  (Temp  was  generated  earlier  in  the  program  as  a synonym  of  the 
operand. ) 

Otherwise,  a single  instruction  STAQ  or  OF  ST  is  generated,  depending 
on  the  specified  source  register. 

:L  DTLOAD  is  called  before  any  arithmetic  operation  on  a double  preci- 
sion table  item  is  generated.  It  calls  DLOAD  to  load  the  double  preci- 
sion operand.  Later,  if  there  is  no  immediate  use  of  that  item  in  the 
FP  register,  the  SAVREG  routine  will  store  the  computed  table  item 
into  a two  word  temp.  Thus,  the  operation,  except  a store,  will  operate 
on  temp  and  will  be  treated  as  a non-table  item. 


Double  Precision  Code  Generation 


In  GFNS  where  the  actual  code  generation  occurs,  whenever  a floating  point  code 
sequence  is  encountered,  the  program  will  check  to  see  if  the  DPFT  flag  is  set,  and 
will  generate  double  precision  or  single  precision  code  accordingly. 

I Q Call  and  Exponentiation 

The  code  generator  calls  the  FOR  I RAN  conversion  library  routine  tv'  handle 
FNCODF  and  DKCODK.  Consequently,  an  entry  point  of  . FCNVD  has  been  added 
in  the  library  routine  list  in  1CA1  to  handle  double  precision  data  conversion. 

Similar  entry  points  have  been  added  for  FOR  1'RAN  exponentiation  library  routine 
calls  to  . F DX  I'l , . FDNPll,  . FOX  I’d,  . FXl’l  to  handle  double  exponentiation  to 
integer,  double  to  double,  double  to  real . and  real  to  double  exponentiation. 

editor 

Within  the  Kditor  phase  a few  procedures  required  modification.  Switch  points  were 
added  to  accommodate  double  precision  items,  A double  precision  flag  was  added  to 
the  calling  sequence  for  the  real  tv'  decimal  conversion  routine  (Rl'CMR.  RTOP  will 
now  (Hit put  double  precision  values  with  the  letter  D for  double  precision  items 
rather  than  an  F as  with  single  precision  items. 

RONS  was  the  routine  requiring  the  most  extensive  modification  within  the  Kditor 
phase.  Kv'NS  is  called  tv'  produce  both  listings  and  object  code  for  constants.  I'lio 
second  parameter  in  the  calling  sequence  tv'  RONS  was  changed  from  a value  tv'  the 
address  of  a value.  In  this  wav.  the  routine  could  easily  obtain  the  second  word  of 
a double  precision  constant.  II  the  constant  is  a double  precision  type,  the  two 
words  are  written  tv-  the  object  file  and  the  proper  constant  is  output  to  the  listing. 

The  I'FMP  chain  is  now  reordered  in  the  Kditor  phase.  The  AS Fq'  for  this  chain 
was  straightened  so  that  the  double  prevision  temporaries  would  come  first,  followed 
by  all  other  types.  1’his  permits  the  double  precision  constants  tv'  be  aligned  on  even 
word  boundaries  pi  system  requirement!. 


Him-  Him'  1 ibrarv 


Only  tho  .lOVl.M  monitor  routine  required  modification  in  the  Run-Time  Library. 
Previously,  it  did  not  have  the  capability  to  monitor  double  precision  items.  As 
with  tlie  direct  code  processing,  a double  precision  type  was  added  to  the  internal 
M itus  list.  A special  code  (bit  flag!  was  added  to  the  calling  sequence  produced  by 
the  Code  generator.  It  the  flag  is  true,  the  value  being  monitored  is  a double  preei- 
^ ion  item.  In  tins  event,  the  monitored  value  is  output  with  the  letter  1>  rather  than 
an  r as  is  done  with  single  precision  items. 


NEW  OPTIMIZER 


A new  optimizer  was  developed  under  the  Improvements  to  JOCIT  contract.  This  new 
optimizer  includes  such  capabilities  as  code  straightening,  dead  variable  analysis, 
unreachable  and  unexitable  code  deletion,  and  several  varieties  of  folding.  It  is  pos- 
sible to  run  the  new  optimizer  independently  from  the  old  one.  Either  optimizer  or 
both  optimizers  may  be  executed  during  a given  compilation. 

DESIGN  CONSIDERATIONS 

The  new  optimizer  uses  a technique  called  P-graphing  to  collect  information  about 
where  a given  variable  is  set  or  used.  The  P-graphing  technique  used  is  discussed 
by  Loveman  f 3 ] . The  P-graph  for  a variable  supplies  answers  to  such  questions  as 
"which  generations  affect  the  value  of  a given  use  of  variable  X?"  and  "which  uses  of 
variable  X result  from  a particular  generation?"  In  addition,  if  the  P-graph  is  com- 
plete (as  it  is  in  this  particular  optimizer),  the  optimizer  answers  questions  such  as 
"is  the  variable  X guaranteed  to  have  the  same  value  at  point  a as  it  is  at  point  b?" 

Rather  than  assuming  that  each  variable  is  both  set  and  used  by  every  subroutine 
called,  an  effort  is  made  to  maintain  lists  of  variables  actually  used  by  internal  pro- 
cedures, so  that  generations  and  uses  will  not  be  created  unnecessarily . This  helps 
not  only  to  allow  better  code  to  be  generated,  but  also  to  cut  down  on  the  size  of  the 
data  base. 

P-graphing  is  a powerful  technique  because  it  pays  attention  only  to  program  flow  and 
not  to  the  way  the  program  was  written.  For  example,  in  the  following  program  seg- 
ment, 


the  old  optimizer  is  unable  to  tell  that  the  two  uses  of  "a"  (In  blocks  1 and  3)  result 
from  the  same  generation  due  to  the  fact  that  the  branch  at  2 is  treated  as  uncondi- 
tional. The  new  optimizer,  however,  does  recognize  the  fact  that  the  two  uses  have 
the  same  value. 

At  the  start  of  the  project  it  was  necessary  to  decide  whether  the  best  course  of  action 
would  be  to  attempt  to  add  enhancements  to  the  old  JOCIT  optimizer  or  to  develop  a 
new  optimizer  with  increased  capability.  The  decision  was  made  in  favor  of  the  new 
optimizer  for  several  reasons.  First,  P-graphing  provides  a more  complete  analysis 
of  data  flow.  This  allows  a higher  degree  of  optimization  since  an  optimizer  should 
only  perform  those  optimizations  which  will  not  change  the  results  of  correct  programs. 
Obviously,  then,  the  more  that  is  known  about  the  flow  of  data  and  control  in  a pro- 
gram, the  safer  the  optimization.  Secondly,  there  have  been  reliability  problems  in 
the  past  with  the  old  optimizer,  and  an  attempt  to  modify  it  could  conceivably  intro- 
duce other  problems.  To  avoid  such  problems  and  to  take  advantage  of  the  data  flow 
information  provided  by  P-graphing,  a decision  was  made  to  adapt  a design  incorpor- 
ating P-graphing  into  the  JOCIT  system. 

The  original  intent  was  for  the  new  optimizer  to  supersede  the  old.  However,  there 
was  insufficient  time  to  incorporate  into  the  new  optimizer  a1 1 of  the  optimizations 
performed  by  the  old  optimizer  and  the  added  optimizations.  For  this  reason,  the  old 
optimizer  was  retained  and  either  optimizer  or  both  can  now  be  run.  In  the  current 
scheme,  the  old  optimizer  runs  before  the  new  one.  (There  is  no  option  for  the  order 
of  execution.)  This  particular  ordering  was  chosen  primarily  because  the  old  optimizer 
performs  optimizations  which  depend  on  the  existence  of  loop  operators.  The  new 
optimizer  transforms  loops  into  sequences  of  ordinary  operators,  so  running  the  new 
optimizer  first  would  degrade  the  performance  of  the  old  one  with  respect  to  loops.  A 
further  advantage  is  that  the  new  optimizer  may  generate  sequences  of  IL  which  the 
old  one  might  not  be  prepared  to  handle.  In  fact,  there  were  several  interface  pro- 
blems between  the  new  optimizer  and  the  code  generator.  It  is  likely  that  the  problems 
woidd  have  been  too  numerous  and  too  hard  to  remedy  had  the  old  optimizer  been  forced 
to  read  the  II,  produced  by  the  new  optimizer. 
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OPTIMIZATIONS  PERFORMED  BY  THE  NEW  OPTIMIZER 


The  following  describes  the  optimizations  performed  by  the  new  optimizer.  Optimi- 
zations performed  by  the  old  optimizer  are  not  discussed  here  except  to  contrast  the 
results  produced  by  each  optimizer.  Optimizations  performed  by  the  old  optimizer 
are  documented  in  the  JOCIT  workbook. 

FOLDING 

Three  types  of  folding  are  performed  in  the  new  optimizer:  constant  folding,  scalar 
folding  and  expression  folding.  These  folding  types  derive  their  names  from  the  value 
types  appearing  on  the  right-hand  side  of  the  assignment  statement.  The  occurrence 
of  a variable  on  the  left-hand  side  of  the  assignment  is  a generation  of  that  variable. 
This  optimizer  is  concerned  only  with  assignments  whose  left-hand  side  is  a scalar. 

Ii  would  be  possible  to  extend  the  folding  the  optimizer  does  to  include  array  elements 
but  this  would  be  difficult.  While  constants  and  scalars  are  properly  classified  as 
expressions,  the  term  "expression  folding"  as  used  here  is  meant  to  exclude  constants 
and  scalars  and  embrace  only  those  expressions  for  which  some  actual  computation  is 
performed. 

The  three  types  of  folding  involve  replacing  a use  of  the  variable  which  was  on  the  left- 
hand  side  of  the  assignment  by  the  right-hand  side  of  the  assignment.  For  example: 


A = 1 


B = A>C 


A = 1 
B *=  l^C 


The  main  reason  for  the  distinction  between  the  types  of  folding  involves  the  differ- 
ences in  when  each  can  and  should  be  applied.  Constant  folding  can  be  applied  to  any 
use  (ns  opposed  to  a use 'generation)  of  the  generation  since  a constant  has  the  same 
value  throughout  the  program.  Scalar  folding  can  be  applied  only  when  the  value  of 
the  scalar  which  was  on  the  right  side  of  the  assignment  has  the  same  value  at  the 
point  of  assignment  as  at  the  use.  The  following  is  an  example  of  when  scalar  folding 
can  not  be  applied: 
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A = SIN  (X) 

B = A 
A = Q 
C = 7*  B 

In  this  example,  the  value  of  A in  line  4 is  not  the  same  as  on  line  2.  Therefore,  it 
would  be  incorrect  to  substitute  A for  B here. 

Expression  folding  is  even  more  restricted  than  scalar  folding.  It  is  incorrect  to 
perform  expression  folding  if  the  value  of  any  of  the  components  of  the  expression 
differs  between  the  generation  and  use  occurrences  of  the  scalar  to  which  the  expres- 
sion was  assigned.  Also,  it  makes  no  sense  to  fold  an  expression  onto  two  or  more  y 

uses  since  this  would  amount  to  u.idoing  common  expression  elimination.  Therefore, 
expression  folding  is  performed  only  when  there  is  exactly  one  use  of  the  generation. 

Folding  can  be  valuable  for  several  reasons.  Constant  folding  can  allow  the  code 
generator  to  make  greater  use  of  immediate  instructions.  Scalar  folding  can  allow  the 
optimizer  to  find  common  expressions  which  have  the  same  value  but  are  not  textually 
thi’  same;  for  instance,  . . . X'Y  . . . Z=Y$.  , . X+7, . Note  that  since  the  new  opti- 
mizer does  not  currently  perform  common  subexpression  elimination,  full  advantage 
is  not  being  taken  of  folding.  Folding  also  increases  the  possibilities  for  dead  store 
elimination  by  making  dead  any  assignments  which  formally  had  uses.  Folding  can 
also  help  the  code  generator  to  maintain  values  in  registers,  eliminating  unnecessary 
loads.  Unfortunately,  little  is  gained  on  the  Honeywell  machine  due  to  the  fact  that 
the  contents  of  the  A and  Q register  must  be  destroyed  for  all  but  the  simplest  compu- 
tations . 

There  is  an  overlap  between  the  folding  done  by  the  old  and  new  optimizers.  However, 
the  new  optimizer  performs  folding  in  some  cases  ir.  which  the  old  one  does  not.  One 
example  of  such  a case  is  shown  above  under  "P-graphing.  " It  is  an  IF.  . . THEN  . . 
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ELSE  construct,  which  might  appear  in  JOVIAL  as  1 KEITH  A $ A = . . . OKIE  1 . . . 

A $.  The  old  optimizer  does  not  recognize  that  the  two  uses  of  A have  the  same  value 
and  are  unaffected  by  the  assignment.  The  new  optimizer  recognizes  that  they  result 
from  the  same  generator  and  would  fold  accordingly. 

Dead  variable  analysis  is  performed  for  the  scalars  in  each  procedure.  If,  at  some 
time,  a generator  has  no  uses  and  the  generation  is  the  result  of  an  assignment  state- 
ment, the  assignment  is  deleted.  While  this  optimization  is  performed  for  assignments 
which  are  dead  at  the  source  level,  it  has  a larger  payoff  with  regard  to  assignments 
which  become  dead  due  to  the  application  of  other  optimizers  such  as  folding.  Con- 
sider the  code  sequence: 


A = expression 
IF  A NQ  Q 


If  this  is  the  only  use  of  that  particular  generation  of  A,  the  expression  will  be  folded 
into  the  IF  and  the  store  will  be  deleted.  Constant  folding  and  scalar  folding  may  also 
create  similar  situations. 

At  the  present  time  there  is  no  prevision  to  deallocate  variables  which  become  unused 
as  the  result  of  dead  store  elimination.  A variable's  I’-graph  contains  sufficient  infor- 
mation so  that  an  optimizer  such  as  this  could  be  added  at  a future  date. 

CODE  STRAIGHTENING 

(.hie  of  the  features  of  the  new  optimizer  is  code  straightening.  The  purpose  of  the 
code  straightening  as  implemented  here  is  to  eliminate  unnecessary  GOTOs  and  to  en- 
sure that  a block  precedes  all  those  blocks  which  it  back  dominates.  Eliminating 
unnecessary  GOTOs  saves  execution  time  and  space  and  allows  good  code  to  be  gen- 
erated for  conditionals  without  complicating  the  front  end. 

The  code  generator  requires  that  value  definitions  (YALSs  or  VAl.Ds)  textuallv  pre- 
cede any  uses  (VALUs).  In  an  unstraightened  program  it  may  be  possible  for  a use  to 
logically  follow  a definition  but  to  textuall  v precede  it.  Code  straightening,  as  imple- 
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mooted  hi* re,  guarantees  that  a generation  will  precede  its  uses. 

l'he  algorithm  used  ean  be  divided  logically  into  two  distinct  parts,  t he  first  part 
eliminates  U'l'i's  to  labeled  CiOTOs.  l'he  imde  sequence 

GOTO  1.1 

It.  GOTO  1.2 

is  changed  to 

llOTO  1,2 

1.1.  r.OTO  1.2 

If  at  any  point  no  referenees  to  1.1  remain  and  there  is  no  fall  through,  the  GOTO  at 
I t is  deleted.  While  sueh  sequenees  are  relatively  rare  in  source  code,  this  situation 
does  occur  in  the  code  which  is  generated  for  conditionals. 

After  GOTOs  to  GOTOs  have  been  eliminated  in  the  manner  described  above,  the  code 
is  reordered  both  to  ensure  that  back  dominators  precede  their  dominatees  and  to 
eliminate  some  more  unnecessary  GOTOs.  Starting  from  the  program  entry  an  attempt 
is  made  to  have  each  block  followed  textually  by  a block  which  also  follows  it  logically, 
l'he  logical  successors  of  a block  ending  in  a GOTO  or  1'SST  are  examined.  If  one 
such  successor  has  not  yet  been  ordered,  it  is  placed  immediately  following  the  block 
being  processed  and  the  other  successor,  it  any,  placed  on  a list  of  candidates  for 
future  processing. 

l'he  following  are  examples  of  the  types  of  optimizations  performed: 


Since  the  block  containing  the  definition  of  1.1  now  follows  the  GOTO,  that 
CiOl'O  is  superfluous  and  can  he  deleted.  The  block  containing  1.2  will  be 
placed  somewhere  el se’Tol lowing  a reference  to  1.2. 

Test  reversal  and  GOTO  elimination 


Since  the  full  through  block  after  a TSST  contains  only  a GOTO,  the  senst 
of  the  TSST  can  be  reversed  and  the  target  changed  to  brunch  directly. 
Since  there  arc  no  other  predecessors  of  the  GOTO,  it  can  be  deleted. 


I’hr  algorithm  is  compl ieated  somewhat  by  the  code  generator's  requirement  that  the 
11  operator  I’l'UM  l>e  both  the  physical  and  logical  end  of  the  program. 

It  should  be  noted  that  the  code  straightening  algorithm  used  is  not  that  of  Earnest, 
et  al.  ( 1 1 . Since  U-graphing  eliminates  much  of  the  need  for  code  straightening  (in 
the  sense  of  moving  code  based  on  whether  it  is  logically  in  a loop  or  not)  it  was  pos- 
sible to  use  a simpler  algorithm.  Inasmuch  as  the  new  optimizer,  as  currently  imple- 
mented. is  not  powerful  enough  to  completely  replace  the  old  one,  it  may  have  been 
better  to  have  used  the  more  complicated  algorithm  in  order  to  enhance  loop  optimi- 
zation. 

t'ONS TAN  1'  AltmiMK  l it' 

Constant  arithmetic  is  also  performed  by  the  new  optimizer.  While  the  constant  arith- 
metic package  is  basically  the  one  which  appeared  in  the  old  optimizer,  but  modified 
to  work  with  the  new  optimizer's  data  base,  some  improvement  in  the  optimization 
obtained  can  be  expected  due  to  the  broadened  scope  of  constant  folding. 

Ihe  new  optimizer  deletes  code  which  is  found  to  be  unreachable  or  unexitable.  Un- 
reachable code  is  code  for  which  there  exists  no  path  from  the  entry  point.  Unexitable 
code  is  code  which  provides  no  path  to  the  exit.  1’he  analysis  for  these  cases  is  per- 
formed globally  so  that  code  which  is  labeled  but  unreferenced,  as  well  as  unlabeled 
following  an  unconditional  CIOTO,  is  deleted.  While  most  of  the  unreachable  code 
which  has  been  found  in  test  cases  so  far  has  been  the  result  of  constant  arithmetic 
deleting  tests,  there  have  been  some  examples  of  unreachable  code  found  in  real  pro- 
grams. 

Ihe  algorithm  used  to  complete  forward  and  back  domiuators  for  the  blocks  in  the  flow 
graph  is  based  on  an  algorithm  by  l arjan  [a]  and  operates  in  O pi  log  n 4 e)  where  n 
is  tin'  number  of  basic  blocks  in  the  program  and  e is  the  number  of  edges.  In  the 
implementation  used  in  the  new  optimizer,  forward  domiuators  are  computed  by  re- 
versing all  of  the  edges  in  the  graph  and  calculating  "back  domiuators"  for  this  re- 
versed graph,  starting  from  the  exit.  I'arian  [ t?  1 has  developed  a faster  algorithm 
(almost  linear)  for  calculating  domiuators.  However,  since  the  dominatin'  calculation 
is  such  a small  part  of  the  optimizer  process,  it  is  unlikely  that  changing  to  the  newer 


algorithm  would  have  an  appreciable  effect  on  compilation  time. 

OPT1MIZ  T U W I A K N KSS  KS 

The  new  optimizer  has  two  main  weaknesses  - it  is  relatively  slow  and  requires  large 
amounts  of  core  to  handle  large  programs.  These  problems  are  explained  at  least  in 
part  by  the  fact  that  the  optimizer  is  almost  completely  untuned  at  the  present  time. 

The  optimization  process  is  iterative  because  performing  one  optimization  ma\  uncover 
other  optimizations  which  can  be  performed.  Tor  example,  folding  ma\  allow  constant 
arithmetic  to  be  performed  in  an  IT  statement.  It  may  then  be  possible  to  determine 
that  one  branch  of  the  IT  is  never  taken  which  may  allow  some  code  to  be  deleted  as 
unreachable.  This  may  allow  additional  folding  to  be  done,  etc.  It  is  possible  to  limit 
the  number  of  iterations  allowed  at  the  cost  of  "overloading"  some  optimizations;  how- 
ever, no  attempt  has  been  made  to  do  so  at  the  present  time. 

The  optimizer  can  be  expected  to  be  large  due  to  the  nature  ot  its  data  base.  In  order 
to  perform  global  optimizations  it  is  necessary  to  maintain  large  amounts  ot  inlorma- 
tion  in  core  unless  compile  time  is  allowed  to  increase  uuronsonnbl \ . There  are  a 
number  of  in-core  tables  in  this  implementation  which  hold  information  about  the  source 
program.  All  of  the  entries  in  a given  table  are  contiguous.  This  allows  smaller 
pointers  and,  hence,  smaller  entry  sizes,  but  this  approach  docs  require  additional 
work  when  a table  is  to  be  expanded  as  opposed  to  using  a linked  list  table  structure. 

Tables  are  allocated  in  both  phase  space  (an  area  the  size  ot  the  dittereneo  ot  the  sizes 
of  the  largest  phase  and  the  optimizer)  and  symbol  table  space.  When  a new  table 
entry  is  needed,  it  is  obtained  from  the  freed  entry  list  of  that  table,  il  possible.  II 
no  entry  can  be  determined  there,  an  attempt  is  made  to  obtain  the  entry  from  the 
unused  space  associated  with  the  table . If  there  is  not  enough  room  there,  an  attempt 
is  made  to  move  the  surrounding  tables  to  obtain  more  space  for  that  table.  If  that 
fails,  then  the  unused  space  for  the  other  table  is  returned.  If  there  is  still  not  enough 
space,  tables  are  shuffled  from  one  area  to  the  other  in  an  attempt  to  obtain  enough 
space.  Finally,  if  there  is  still  not  enough  space  and  the  symbol  table  has  not  been 
expanded  to  its  limit,  a system  call  is  made  to  obtain  more  space. 


Rather  than  to  force  each  routine  which  creates  table  entries  to  check,  each  time  the 
space  manager  returns,  to  see  if  there  really  was  enough  space  to  satisfy  the  request, 
a block  of  space  in  each  area  is  held  in  the  reserve.  This,  at  least  in  theory,  allows 
the  module  which  is  currently  executing  to  terminate  gracefully.  Then,  between  mod- 
ules, a check  is  made  to  see  whether  or  not  the  reserve  has  been  used.  If  so,  appro- 
priate action  can  be  taken.  If  the  space  manager  is  unable  to  satisfy  a request  after 
the  reserve  has  been  used,  it  is  forced  to  terminate  the  compilation. 

In  practice,  a number  of  large  programs  have  caused  the  reserve  to  be  exhausted  and 
compilation  to  be  terminated.  Experimentation  with  the  size  of  the  reserve  would  pro- 
bably lead  to  a size  which  would  allow  larger  programs  to  be  compiled  in  a given  core 
size.  Each  routine  which  calls  the  space  handler  would  provide  it  with  an  address  of 
a routine  which  could  allow  a more  graceful  exit  when  there  is  no  more  available  space. 
An  even  better  method  would  be  to  devise  a scheme  in  which  pieces  of  programs  could 
be  optimized.  This  could  require  considerable  work,  however,  and  there  was  insuffi- 
cient time  to  investigate  any  of  these  possibilities  to  any  extent. 

i'here  were  several  problems  which  made  the  final  result  less  than  it  might  have  been 
under  ideal  circumstances.  Perhaps  the  most  important  of  these  was  the  lack  of  good 
interactive  debugging  facilities  on  TSS.  An  interactive  debugger  such  as  PCF  on  CSTS 
or  HOT  on  the  OEt'-lO  could  have  made  the  job  significantly  easier.  A good  deal  of 
effort  was  spent  building  in  debugging  dumps  and  traces.  While  these  proved  valuable 
in  the  debugging  effort  and  could  not  have  been  eliminated  entirely,  even  if  an  on-line 
debugger  had  been  available,  the  space  occupied  by  the  debugging  routines  was  used 
for  data  when  none  of  the  debugging  options  were  on.  This  caused  some  difficulties 
in  reproducing  bugs,  however,  because  some  problems  which  occurred  when  there 
were  no  debugging  options  on  were  masked  with  debugging  on  because  the  compilations 
ran  out  of  space  before  the  problem  occurred  . 

1'he  debugging  features  developed  include  formatted  table  dumping,  tracing  tat  l differ- 
ent levels)  and  data  change  monitoring.  Formatted  dumps  of  all  of  the  major  tables 
in  the  optimizer  are  available  during  the  execution  of  the  compiler  and  all  tables  are 
dumped  if  an  internal  inconsistency  (OERROR)  is  detected. 


Tracing  is  also  triggered  by  control  card  option  and  CONTROL  statement.  The  levels 
of  tracing  available  are  major  module,  routines  within  major  modules,  utility,  and 
low  level  utility.  Through  use  of  the  CONTROL  statement,  tracing  can  be  varied  for 
each  procedure  being  compiled. 

Data  change  monitoring  is  available  for  specific  core  locations  and  for  table  entires. 
Whenever  a traced  subroutine  is  called,  the  old  value  for  the  item  being  monitored 
is  compared  with  the  current  value.  A dump  of  the  item  is  produced  if  there  has  been 
a change.  Data  change  monitoring  is  available  onh  through  the  use  of  the  CONTROL 
statement. 

The  other  major  difficulty  arose  because  of  a lack  of  available  disk  space.  Due  to 
the  fact  that  there  was  only  space  enough  for  one  optimizer  compiler  for  the  bulk  of 
the  time,  it  was  necessary  to  link  aU  new  (and  unstable!  modules  into  one  compiler. 
This  meant  that  everyone  had  to  contend  with  everyone  clse's  bugs.  Things  would 
have  gone  smoother  had  it  been  possible  to  debug  unstable  modules  individually  and  to 
"make  public"  only  those  modules  which  were  stable. 

This  problem  was  circumvented  to  a certain  extent  by  introducing  control  card  options 
to  allow  certain  modules  (e.g. , folding)  to  be  bypassed.  In  other  cases  (for  example, 
when  the  space  manager  was  modified)  this  could  not  be  done. 

Several  interesting  and  as  yet  unanswered  questions  have  been  raised  as  a result  of 
the  wprk  on  this  project.  One  concerns  a possibly  novel  approach  to  optimization. 
Another  concerns  the  manipulation  of  l’-graphs. 

At  the  start  of  the  project  the  possibility  of  using  Kirchoff's  laws  I til  to  obtain  relative 
frequences  of  execution  for  the  various  blocks  in  a program  was  investigated.  Kir- 
choff's law  was  stated  with  regard  to  electrical  circuit  theory  and  says  "flow  in 
flow  out."  In  the  case  of  flow  graphs,  we  also  know  that  the  flow  along  any  path  is 
non-negative.  It  is  easy  to  deduce  local  information. 
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If  wo  let  F stand  for  the  flow  into  lor  out  off  Nock  and  f be  the  How  from  block  i 
i i ij 

to  block  j then  K.  * K , and  F,  * F since  F , ~ f and  F = f and  F,  = f * f, 
l 3 1 .1  _K:  3 1 d 113  13 

and  all  of  the  f.  0. 

ii 

It  is  difficult  to  determine  the  relationships  between  blocks  which  are  the  relations  to 
be  determined  ami  which  indicate  whether  or  not  it  is  possible  to  tell  anything  definite 
about  the  relationship.  f.n  the  flow  diagram  above,  it  is  impossible  to  tell  whether 
3 or  3 has  a higher  frequency  of  execution  without  knowing  something  about  the  pro- 
bability of  taking  one  branch  or  the  other  at  1'. 

Relative  flow  frequencies  are  important  because  it  is  desirable  to  move  code  from  a 
region  of  high  frequency  to  a region  of  lower  frequency.  By  calculating  frequencies, 
it  mav  be  possible  to  perform  code  motion  without  regard  to  formal  loops.  It  should 
be  noted,  however,  that  this  method  has  drawbacks.  No  definite  relationship  can  be 
established  between  the  predecessor  of  a HO  Willi  F loop  and  the  code  within  the  loop 
itself.  For  example: 


No  relation. hip  can  !>u  established  between  1 and  3.  I'll i s is  correct  because  1 may  be 
executed  while  3 is  not  (1  31  or  3 mav  be  executed  many  times  while  1 is  executed 

onlv  once  (3  ■ 11. 

It  is  not  clear  tiow  time-consuming  the  calculation  of  frequencies  would  be  or  what 
the  pavoff,  if  am  , would  be  in  terms  of  improved  optimization.  No  attempt  was  made 
to  program  the  frequence  evaluator  or  to  prove  that  it  would  work  in  all  eases  due  to 
the  limited  time  available  for  implementation. 

Another  interesting  question  concerns  P-graphing.  Although  no  empirical  evidence 
has  been  gathered  with  respect  to  the  new  optimizer,  it  would  appear  that  P- graphing 
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takes  a sizeable  amount  of  the  time  required  for  optimization.  Since  the  algorithm 
used  in  this  optimizer  was  originally  developed,  an  algorithm  which  is  faster  (at  least 
for  very  large  programs)  has  been  published  [ if  ] . Whether  it  would  be  faster  tor 
programs  which  are  small  enough  to  be  optimized  is  not  obv  ious. 

There  may  be  another  approach  which  could  prove  fruitful.  Common  variables  tend 
to  have  P-graphs  which  are  basically  the  same  - - composed  chiefly  of  implicit  uses 
and  generations  at  calls  to  external  procedures  and  a relatively  small  number  of  uses 
elsewhere.  Would  it  be  possible  to  construct  a basic  P- graph  template  to  obtain  the 
P- graph  for  each  individual  variable?  it  so,  would  it  be  faster  than  constructing  the 
P- graph  from  scratch? 

Although  a comprehensive  performance  analysis  of  the  new  optimizer  was  not  carried 
out,  some  figures  are  available  with  respect  to  the  l series  tost  eases.  There  are 
roughly  100  such  test  eases.  Of  those  for  which  compilation  statistics  are  available 
( 7(> I , the  smallest  was  under  30  source  lines,  and  the  larger  programs  were  between 
100  and  1 T>0  source  lines.  Object  sizes  ranged  from  33  (octal)  words  to  3031  words 
unoptimized  and  da  to  3077  optimized.  ( These  ligures  exclude  (TOMPOOI,  compila- 
tions which  are  not  opt  i m iz  able.  ) C'ompil  at  ion  times  ranged  from  .0003  to  ,003a  un- 
* optimized  and  .000  1 to  .0007  optimized. 

In  01  eases  the  optimized  code  was  smaller,  in  11  cases  there  was  no  change,  and  in 
0 eases  the  optimized  code  was  larger.  In  absolute  terms  the  best  test  ease  was  one 
which  shrank  from  3 173  to  001  words.  Percentagewise,  the  best  results  were  obtained 
with  a program  which  was  301  words  unoptimized  and  >3  words  optimized.  A total  ot 
30  test  cases  experienced  what  could  be  described  as  significant  reductions  in  size 
(defined  here  as  -*100  words). 

The  largest  degradation  was  13  words.  This  is  due  to  the  tact  that  the  code  generator 
does  not  remember  the  length  of  a Hollerith  function  which  has  been  \ Al.sed  and  is 
forced  to  generate  a subroutine  call  rather  than  use  an  l ls  instruction,  other  increases 
in  the  generated  code  are  due  to  the  fact  that,  on  the  Ilonevwell  machine,  it  takes  one 
instruction  to  increment  memory,  but  two  instructions  to  add  one  to  a register  and 
store  the  value.  In  addition,  there  were  It!  programs  in  which  there  was  only  a 
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small  decrease  (1-20^  words)  in  program  size. 

Thus,  a substantial  reduction  in  size  occurred  in  29  cases,  and  there  were  no  signifi- 
cant changes  in  31  cases.  It  should  be  cautioned,  however,  that  test  cases  tend  to  be 
more  amenable  to  optimization  than  actual  programs.  It  is  unlikely  that  any  real  pro- 
grams would  exhibit  the  size  reductions  of  nearly  50^  which  were  exhibited  in  12  of 
the  test  cases.  It  is  also  unlikely  that  real  programs  would  show  the  sort  of  degrada- 
tions which  occurred  in  four  test  cases.  Real  programs  can  be  expected  to  show  a 
modest  improvement  in  most  cases,  if  not  all. 

POSSIBILITIES  FOR  FUTURE  IMPROVEMENTS  TO  THE  OPTIMIZER 

The  new  optimizer  is  probably  more  significant  for  the  potential  it  provides  than  for 
the  optimizations  it  actually  performs.  The  new  optimizer  enhances  the  folding  and 
constant  arithmetic  capabilities  of  the  JOCIT  compiler  and  adds  code  straightening 
and  dead  store  elimination.  It  provides  a degree  of  optimization  for  some  programs 
which  were  formerly  unoptimizable  under  the  JOCIT  system  (notably  the  14  SAC  pro- 
grams). 

More  importantly,  however,  it  provides  a base  to  which  more  powerful  optimizations 
and  additional  diagnostic  capabilities  can  be  added.  The  following  is  a list  of  possible 
additions  and  improvements.  It  is  not  intended  to  be  exhaustive,  but  merely  to  pro- 
vide an  idea  of  what  could  be  done. 

1.  The  optimizer  can  use  some  tuning  and  improvements  with  respect  to 
compilation  time  and  space  required.  Some  improvement  could  be  seen 
with  minor  testing  and  modification.  The  size  of  the  compiler  and  size  of 
the  reserve  could  be  specified  bv  control  card  options.  Modifying  the  opti- 
mizer so  that  it  could  optimize  sections  of  code  would  require  a significant 
amount  of  work,  but  it  would  enable  larger  programs  to  be  compiled. 

2.  Loop  optimizations  could  be  added.  Currently  the  old  optimizer  performs 
all  of  the  loop  optimizations  for  JOCIT.  There  is  some  code  for  code  re- 
distribution in  the  new  optimizer  but  it  is  incomplete  and,  therefore,  by- 
passed. The  approach  to  loop  optimization  could  be  the  conventional  ap- 
proach or  the  experimental  approach  based  on  execution  frequencies. 
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Folding  could  be  extended  to  include  array  references  and  overlaid  vari- 
ables. Overlaid  variables  could  be  handled  by  combining  their  P-graphs. 
Handling  array  references  would  be  more  complex. 

An  improved  register  allocation  scheme  could  be  developed.  The  P-graph 
for  a variable  provides  sufficient  information  to  determine  what  variables 
are  good  candidates  to  be  assigned  to  registers.  At  present,  most  of  this 
information  is  lost  because  the  code  operator  assigns  registers  and  the 
P- graphs  no  longer  exist  when  registers  are  assigned.  Only  that  informa- 
tion which  can  be  transmitted  via  the  VALD^VALi/VAI.T  mechanism  sur- 
vives. A global  register  allocation  algorithm  would  be  a major  undertak- 
ing. However,  there  are  some  smaller  changes  which  could  be  made  at 
a lesser  cost: 

a.  VALSs  or  VALDs  could  be  created  for  merges  as  well  as  genera- 
tions. This  could  result  in  better  code  for  item  switches. 

b.  VALDs  could  be  generated  for  parameters. 

c.  VALDs  could  be  used  instead  of  VALSs  in  some  cases  to  eliminate 
unnecessary  stores. 

It  should  be  noted,  however,  that  these  modifications  would  have  a greater 
affect  on  a machine  with  more  registers  than  the  Honeywell  machine. 

It  would  be  possible  to  diagnose  cases  in  which  a variable  may  be  used 
before  it  is  set.  A variable  P-graph  together  with  an  indication  of  whether 
the  variable  is  preset  provides  sufficient  information  to  detect  this  condi- 
tion. 

Self  tests  (e.g.  , A EQ  A)  and  self  assignments  (e.g. , A = A)  can  be  deleted 
with  relative  ease.  Self  tests  occur  in  some  forms  of  FOR  loops. 

The  code  for  Hollerith  functions  could  be  improved  if  the  code  generator 
remembered  the  length  of  the  result  of  a function  which  was  VALSed.  This 
would  enable  EIS  instructions  to  be  used  in  place  of  a subroutine  call. 
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The  user  interface  could  be  cleaned  up  in  several  cases,  dome  of  the 
OERROR  messages  could  be  replaced  by  messages  which  would  be  more 
meaningful  to  users.  The  present  OPT  options  tend  to  be  more  historical 
than  logical.  The  options  and  defaults  could  be  reassigned  to  make  the 
optimizer  easier  to  use. 
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APPKND1X  A - .1CVS  ami  SAC  Program  Comparisons 


rhe  following  table  presents  a comparison  of  the  various  modes  of  compilation  for 
the  JCYS  tests.  There  are  four  categories: 

a.  No  optimization  (NOPT) 

b.  Old  optimizer  (OP'l'/l/) 

c.  New  optimizer  (OPT/2/) 

d.  Combined  old  and  new  optimizers  (OPT/12/) 

There  was  essentially  no  difference  between  the  old  compiler  and  the  new  compiler 
in  the  NOPT  and  OPT/l/  modes,  but  this  was  expected  since  no  changes  were 
planned  in  that  area.  Therefore,  only  the  above  modes  are  compared  in  the  new 
compiler.  The  compile  times  shown  are  seconds  and  the  sizes  of  the  object  code 
are  in  decimal.  The  asterisk  indicates  a fatal  error. 

Time  (seconds)  Size  (decimal) 

JCVS 

Test  NOPT  OP  T /l/  OPT/2/  OPT/12/  NOi’T  OPT/l/  OPT/2/  OPT/12/ 

CI.ASS1 


Cl 

31.3 

48.  1 

♦ 

1 1 r>.  9 

2107 

1870 

♦ 

1664 

C2 

28.  1 

40.  0 

♦ 

79.  6 

1830 

1504 

♦ 

1406 

c:i 

35.  (l 

01.2 

♦ 

* 

2702 

2077 

♦ 

♦ 

Cl 

27.  1 

30.2 

132.  1 

♦ 

2004 

1770 

1694 

♦ 

cr> 

22. 0 

40.0 

* 

* 

2100 

1855 

* 

♦ 

Cti 

30.7 

55.8 

% 

♦ 

2421 

2150 

* 

♦ 

Time  (seconds)  Si/e  (decimal) 

JCVS 

Test  NOPT  OPT/1/  OPT/2/  OPT/12/  NOPT  OPT/l/  OPT/2/  OPT/12/ 


CLASS2  (This  class  tests  error  detection  capabilities  of  the  compiler) 


ER1 

19.4 

♦ 

65.9 

* 

1046 

* 991  * 

ER2 

1.1 

1.  1 

1.1 

1.4 

4 

4 4 4 

ER3 

This  test  deliberately  produces  a 

fatal  error  - 

all  modes  operated  in 

same 

manner. 

ER4 

1.1 

1.1 

l.l 

1.4 

5 

5 5 5 

ER5 

1.1 

1.  1 

1.4 

1.4 

7 

6 4 4 

Compool 

Test 

COMP 

1.8 

1.8 

1.8 

1.8 

109 

109 

109 

109 

CTST 

3.2 

4.3 

4.3 

7.2 

215 

176 

176 

176 

PA 

1.1 

1.1 

1.  1 

1.4 

27 

6 

16 

6 

PB 

1.1 

1.  1 

1.1 

1.4 

18 

6 

6 

6 

CPI 

.7 

.7 

.7 

. 7 

5 

5 

5 

5 

CP2 

.7 

.7 

. 7 

. 7 

0 

0 

0 

0 

TSTCP 

1.8 

2.2 

2.2 

2.9 

89 

75 

75 

75 

39 


Time  (seconds) 


Size  (decipml) 


JOYS 


Test 

NOPT 

OPT/1/ 

OPT/2 

/ OPT/12/ 

NOPT 

OPT/1/  OPT/2/  OPT/12/ 

A Series 

TE01 

2.2 

2.9 

3.6 

4.3 

119 

108 

108 

104 

TF.02 

2.5 

2.2 

4.3 

5.0 

124 

123 

123 

123 

TE03 

•>  o 

3.2 

3.6 

4.7 

146 

143 

143 

143 

TE04 

1.4 

2 . 2 

2.5 

2.  9 

63 

64 

58 

61 

TE05 

2.  5 

3.2 

4.0 

5.0 

97 

97 

96 

96 

TE06 

2. 2 

2.9 

3.2 

4.0 

3185 

3177 

3188 

3180 

TE07 

1.1 

1.4 

1.4 

1.8 

24 

24 

24 

24 

TE08 

2.  5 

2.9 

3.6 

4.3 

157 

153 

155 

155 

TE09 

5.4 

7.2 

6.8 

9.7 

569 

505 

503 

502 

TE10 

1.8 

•>  •> 

2.5 

2.9 

66 

62 

60 

59 

TE11 

6.5 

8 . 3 

10.8 

14.4 

620 

394 

426 

370 

TE12 

1.4 

1.8 

1.8 

2 . 2 

52 

52 

48 

54 

10 


Time  (seconds) 


Size  (decimal) 


JCVS 


Test 

NOPT 

OPT/1/ 

OPT/2/  OPT/12/ 

NOPT 

OPT/1/ 

OPT/2 

/ OPT/1 

B Series 

TE14 

2.9 

4.0 

5.8 

6.  1 

189 

187 

190 

190 

TE15 

2 . 2 

2.9 

3.  2 

4.3 

219 

213 

221 

215 

TPOL 

1.1 

1.  1 

1.1 

1.1 

21 

21 

21 

21 

TE20 

1.4 

2.2 

2.2 

2.9 

48 

51 

46 

IS 

IFFR 

. 7 

.7 

.7 

. 7 

4 

4 

4 

4 

FR1F 

1.4 

2. 2 

2.5 

3.2 

04 

03 

03 

03 

BMLO 

2.2 

2.  5 

2.9 

3.0 

113 

113 

113 

113 

M1NU 

1.4 

1.8 

1.8 

2 ° 

55 

47 

55 

40 

STCT 

1.1 

1.1 

1.1 

1.4 

4 

4 

4 

4 

LABL 

1.  1 

1.4 

1.4 

1.8 

10 

10 

10 

10 

TABL 

2.5 

2.9 

3.2 

3.  0 

105 

104 

104 

104 

CSTP 

. 7 

1.  1 

1.1 

1.4 

3 

3 

3 

3 

DEFI 

1.4 

1.8 

2.5 

2.  9 

48 

40 

50 

40 

PRES 

1.  1 

1.4 

1.4 

1.8 

31 

31 

31 

31 

TRAN 

1.4 

1.8 

1.8 

2 . 2 

50 

50 

50 

50 

11 


JCVS 

Test 


Time  (seconds) 


Size  (decimal) 


NOPT  OPT /l/  OPT/2/  OPT/12/  NOPT 


OPT/1/  OPT/2/  OPT/12/ 


C Series 


CAPY 

8.3 

9.7 

16.9 

18.4 

445 

409 

380 

380 

1)1  R1 

6.  1 

7.  6 

10.4 

14.0 

487 

346 

335 

347 

DIRE 

13.3 

17.3 

44.6 

58.0 

1229 

995 

984 

984 

STC 

5.0 

5.  8 

7.2 

8.3 

599 

549 

572 

554 

STOP 

2.5 

3.2 

4.0 

4.3 

163 

161 

161 

161 

CLOS 

2.9 

4.0 

5.  0 

6. 1 

197 

185 

188 

187 

MODE 

4.3 

5.  4 

6.  8 

7.9 

270 

262 

263 

263 

WORD 

1.8 

•>  O 

O r. 

2.9 

82 

82 

82 

82 

LSWD 

1.4 

1.8 

2.2 

2.5 

66 

66 

66 

66 

APS 

2.2 

2.9 

3.  (> 

4.3 

137 

119 

116 

115 

Itl.NK 

1.4 

1.8 

1.8 

2.5 

74 

74 

74 

74 

LL1T 

10.  1 

14.8 

16.6 

23.0 

977 

941 

936 

935 

The  following  table  gives  the  compile  time  in  seconds  and  the  size  of  the  generated 
object  code  in  decimal  for  fourteen  SAC  programs  that  had  fatal  errors  on  the  old 
optimizer.  These  results  were  not  obtained  with  the  latest  version  of  the  compiler 
produced  under  this  contract,  since  the  SAC  programs  were  removed  from  the 
disk  earlier.  However,  the  values  should  be  a good  indication  of  the  expected 
results  with  the  latest  compiler.  An  asterisk  indicates  a fatal  error. 


Time  (seconds) 


Size  (decimal) 


SAC 

Program 

NO  PT 

OPT/1/ 

OPT/2 

/ OPT/12/ 

NOPT 

OPT/1  / OPT/2/ 

OPT/ 12/ 

B PAD 

9.0 

♦ 4 

19. 1 

♦ * 

508 

♦ * 

•178 

♦ 4 

BPBD 

137.5 

** 

1110.2 

♦ * 

8345 

4 4 

7588 

4 ♦ 

BPCD 

97.2 

44 

*(570.2) 

4 ♦ 

7268 

♦ * 

*(6394) 

♦ * 

B POD 

29.5 

* * 

120.2 

♦ * 

2068 

♦ * 

1 836 

♦ ♦ 

B PED 

47.9 

♦ * 

173.2 

♦ * 

3339 

♦ 4 

3127 

44 

BPFD 

111.2 

44 

718.2 

* * 

6799 

♦ ♦ 

6349 

♦ 4 

BP1D 

1 14.  S 

44 

814.0 

♦ 4 

9847 

♦ * 

8405 

4 ♦ 

BPOR 

32.  8 

44 

140.0 

♦ * 

2422 

* 4 

2259 

44 

BPPR 

28.8 

♦ 4 

1 56 . 6 

♦ * 

1984 

♦ 4 

1 900 

♦ 4 

BPQR 

88.  9 

♦ * 

581.0 

♦ * 

7002 

♦ ♦ 

6482 

4 4 

BPSA 

32.0 

* * 

118.4 

♦ * 

2627 

♦ * 

2539 

♦ 4 

BPTR 

112.7 

44 

1385.3 

♦ * 

8539 

♦ * 

7399 

4 4 

B PI'  R 

64 . 8 

44 

192.6 

♦ * 

4766 

♦ 4 

4682 

4 4 

B PVR 

30.6 

44 

158.4 

♦ * 

6224 

♦ ♦ 

6 1 08 

4 4 

The  double  asterisks  indicate  that  the  compilation  for  those  modes  was  not  attempted 
after  some  corrections  had  been  made  to  the  old  optimizer.  Therefore,  the  status 
of  those  modes  is  unknown  until  the  SAl’  programs  can  be  restored  to  the  disk  and 
retried  with  the  new  compiler.  Previously,  however,  all  of  the  fourteen  SAT  pro- 
grams had  fatal  errors  in  the  old  compiler. 

The  program  BPCI)  is  shown  with  a fatal  error  under  the  OPT  2 ‘ mode.  Earlier 
it  had  been  compiled  successfully  in  570.2  seconds  and  generated  **394  words  of 
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object  code.  Since  that  compilation,  however,  the  upper  limit  to  which  the  compiler 
was  allowed  to  grow  during  a compilation  was  lowered.  This  apparently  caused  a 
lack  of  sufficient  table  space  to  successfully  complete  the  compilation  of  BPCD.  A 
similar  situation  occurred  with  a number  of  the  CLASS  1 JCYS  tests  compiled  under 
the  OPT/12/  mode. 


